1. Field of the Invention
The present invention relates to computing systems, and more particularly, to semaphoring hardware and a control mechanism thereof.
2. Discussion of the Related Art
A semaphore is a hardware or software flag. In multitasking systems, a semaphore is a variable with a value that indicates the status of a common resource. The semaphore is used to lock the resource that is being used. A process needing the resource checks the semaphore to determine the resource's status and then decides how to proceed.
In programming, for example in UNIX systems, semaphores are a technique for coordinating or synchronizing activities in which multiple processes compete for the same operating system resources. A semaphore is a value in a designated place in operating system (or kernel) storage that each process can check and then change. Depending on the value that is found, the process can use the resource or will find that it is already in use and must wait for some period before trying again. Semaphores can be binary (0 or 1) or can have additional values. Typically, a process using semaphores checks the value and then, if it is using the resource, changes the value to reflect this so that subsequent semaphore users will know to wait.
Semaphores are commonly used for two purposes: to share a common memory space and to share access to files. Semaphores are one of the techniques for interprocess communication (IC). The operating system provides a set of interfaces or “functions” for managing semaphores.
In general, an example of a hardware based semaphore may be described in terms of a status bit of a host status register that allows access to the input/output registers of a host controller of a device. The polling and capture of the status bit by software allows the software access to the input/output registers of the host controller to initiate transactions.
An example of a hardware based semaphore is a status bit, an INUSE—STS bit, utilized in a Host Status Register of a System Management Bus (SMBus) host controller operating in an Intel I/O Controller Hub 4 (ICH4). The INUSE—STS bit is used as a semaphore for various independent software threads that may need to use the ICH4's SMBus logic, and has no effect on hardware. After a full PCI reset, the INUSE—STS bit is equal to a 0, and a read to this bit returns a 0. If the INUSE—STS bit equals a 1, after a first read, subsequent reads will return a 1. A write of a 1 to this bit will reset the next read value to 0. Writing a 0 to this bit has no effect. Software can poll this bit until it reads a 0, and the software will then own the usage of the host controller.
The Intel ICH4 SMBus Driver implements a mechanism to allow both system management interrupt (SMI) and Operating System present software (the Intel ICH4 SMBus Driver) to cooperatively use the SMBus host controller hardware in the Intel ICH4 component. This mechanism employs the hardware-based semaphore INUSE—STS bit to allow either the SMI or the driver to claim ownership of the SMBus host controller for an arbitrary period of time. While either the SMI or the driver own the INUSE—STS semaphore, the other party must poll the INUSE—STS bit until ownership is achieved. For SMI, this involves scheduling a periodic SMI interrupt. The mechanism assumes both the SMI and the driver are cooperative in that they will release the INUSE—STS semaphore when they have completed their transaction. However, this mechanism does not provide timely access to the SMBus host controller by either the SMI or the driver, only eventual access.
Another example of a hardware based semaphore is an INUSE—STS bit utilized in an internal thermal sensor of a Northbridge chip. The Northbridge chip may contain devices, e.g., a memory controller, a graphics controller, or a Accelerated Graphics Port (AGP) bus controller capable of producing enough heat to damage the part. The internal thermal sensor provides a closed loop feedback path, and an emergency indicator. The internal thermal sensor may have two trip points. A trip point may be implemented with a comparator which indicates whether the temperature is above or below its set point.
Multiple entities, e.g., the memory controller, the graphics controller, or the AGP bus controller, have software drivers vying for control of a set of input/output (I/O) registers within the internal thermal sensor. Software drivers have the ability to program the temperature trip points. This may be used to either change the trip point, or to measure the current temperature. The internal thermal sensor may be programmed to cause hardware throttling and/or software interrupts. Hardware throttling includes 3D throttling, main memory throttling, and local memory throttling. Interrupts include System Control Interrupt (SCI), SMI, SERR, or graphics interrupt ( graphics INTR). This mechanism also assumes that the memory controller, the graphics controller, or the AGP bus controller software drivers are cooperative in that they will release the INUSE—STS semaphore when they have completed their transaction. Again, this mechanism does not provide timely access to the internal thermal sensor by either of the software drivers, only eventual access.
What is needed is an algorithm that utilizes the semaphoring capability of a hardware device to allow multiple entities to efficiently arbitrate for control of the hardware device thus allowing timely access to the hardware by an entity.